Distributed file systems are known in the related art for using tokens to maintain data consistency. These tokens include class such as data, attribute, size and name, etc. Each token possesses states (names) called read and write. A node holding a read-level data token for example, is permitted to read the file matching that token. A node holding a write-level data token is permitted to write on a file matching that token. A read-level token can be simultaneously held by multiple nodes but a write-level token can only be held by one particular node. So multiple nodes can simultaneously read the same file but multiple nodes cannot simultaneously write on a file.
Methods for issuing data tokens include a method to issue tokens granting rights to the entire file, and a method for issuing tokens granting rights to a limited range of data (for example, up to a certain byte from the first byte of a file).
These tokens may for example be provided in the format shown in FIG. 5. The file ID field 31 shows what kind of file the token is for. The revoke token class field 32 shows the class of token (data, attribute, size, name, etc.). The range specifier field 33 designates the range of the data.
This distributed file system of the related art typically has three cases. In a first case, multiple nodes can refer to the same file by read-only. In a second case, where one node reads and writes on a file, files access is extremely efficient. In a third case, however where multiple file nodes read and write on the same file, the performance drastically deteriorates.
The processing flow in the above third case is described while referring to the flow chart in FIG. 6. A precondition here is that the client A holds a write data token for file X. Another precondition is a state where latest update data on file X is not shown on the disk (prior to write). The processing flow for the precondition is shown by the thick lines with arrows.
When the client B completes I/O processing (write processing or read processing) for file X (process 101), the client B refers to its own token hold table and decides (process 102) whether or not the correct token (read-level token for read processing, write-level token for write processing) for file X is held. The processing shifts to process 110 when the client B decides it holds the correct token for file X.
When the client B does not hold a correct token for file X, it issues a request to the server C for the correct token. When the request for a token is received, the server C refers to its own token management table and decides (process 103) whether or not a client (computer) is holding the write-level token for file X. If there is no client holding the write-level token for file X then the processing shifts to process 108. In this case however, the client A holds the write-level token for file X so the server C requests a token revoke (return) for the client A.
When the client A receives the revoke request from the server C, it decides whether or not there is dirty data that is not shown (not yet written) in the disk in its own cache holding the file X data (process 104). If there is no dirty data, the processing shifts to process 106. However, if there is dirty data in the client A, then the client A writes the dirty data of file X back onto the disk (or server) (process 105). The client A next deletes the write-level token for file X from its own token hold table, and notifies the server C of return (sending back) of the token (process 106). When server C receives this return notification, it reflects (shows) the return of the token in its own token management table (process 107). The server C next reflects (shows) the granting of the request token to client B in the token management table processing, and sends a message to the client B informing that the requested token has been granted. The I/O processing of the disk (or server) is then performed (process 110) when finished showing that the token is for client B.
In other words, communications between nodes occur four times and disk I/O operation occurs two times; in a state where a node is holding a write-level data token for a certain file, and another node has accessed that same file.
[Patent Document 1]
JP-A No. 322306/2000
[Non-patent Document 1]
SGI® Infinite Storage Shared File System CXFX™: A High-Performance Multi-OS File System from SGI
Laura Shepherd and Eric Eppe
<URL: http://www.sgi.com/pdfs/2691.pdf>
In distributed file systems of the related art, 2 disk I/O processes and 4 inter-node communications occur during I/O processing by a node for a file whose token is held by another node. This processing must furthermore be performed in sequence, and time is required for I/O processing of the disk causing the problem that system performance deteriorates.